4장 가상 네트워크 만들기
VPC
Virtual Pirvate Cloud는 AWS에서 제공하는 가상 네트워킹 서비스로, 사용자가 정의한 가상 네트워크에서 AWS 리소스를 실행할 수 있게 해준다.
생성 내용
VPC를 생성할 때 사전에 네트워크 정보를 결정한다. 결정 항목은 다음과 같다.
항목 | 값 | 설명 |
---|---|---|
이름 태그 | sample-vpc | VPC를 식별하는 이름 |
IPv4 CIDR 블록 | 10.0.0.0/16 | VPC에서 이용하는 프라이빗 네트워크의 IPv4 주소 범위 |
IPv4 CIDR 블록 | IPv6 블록 없음 | VPC에서 이용하는 프라이빗 네트워크의 IPv6 주소 범위 |
tenancy(테넨시)) | 기본값 | VPC 리소스의 전용 하드웨어에서의 실행 여부 |
IPv4 CIDR 블록
프라이빗 네트워크에서 이용할 수 있는 IP 주소범위는 3가지로 제공된다.
- 24비트 블록 : 10.0.0.0 ~ 10.255.255.255
- 20비트 블록 : 172.16.0.0 ~ 172.31.255.255
- 16비트 블록 : 192.168.0.0 ~ 192.168.255.255
사용할 범위에 따라서 블록을 선택한다.
어떤 범위를 이용해도 달라지는 점은 없으니까 그냥 큰거 하자
IPv6 CIDR 블록
VPC에서 IPv6 이용 여부를 지정한다. 특별한 의도가 없으면 없음
선택
테넨시
VPC상의 리소스를 전용 하드웨어에서 실행하리 지정.
기본으로 설정하면 다른 AWS계정과 하드웨어 리소스 공유된다.
신뢰성이 중요한 시스템에서는 전용
으로 설정. 단 돈 든다.
VPC 생성 순서
VPC - > VPC 생성
name태그는 별도로 바꾸지 않는다.
다양한 리소스 만들 때 이름 규칙 만들어 두고 시작하면 편하다
ex) 시스템 이름 - 리소스 이름 -(리소스 식별자)
서브넷과 가용 영역
VPC의 IP 주소 범위를 나누어서 서브넷을 만들어야한다.
IP 주소 범위를 나누는 이유는 2가지 이유가 있다.
- 역활 분리 : 외부에 공개하는 리소스 여부를 구별
- 기기 분리 : AWS안에서의 물리적인 이중화 수행.
역할분리
리소스가 담당하는 역할에 따라 분리.
로드 밸런서처럼 외부 공개가 목적인 리소스는 외부에서 접근이 허용되어야 하지만 반대로 DB서버는 외부에 공개되어서는 안된다.
즉, public private를 나누기 위해서
기기 분리
내결합성을 [1] 높이기 위해서 기기 분리
여러 가용영역을 구성하여 여러 서브넷을 동시에 이용하지 못하는 가능성을 낮출 수 있다.
IPv4 CIDR 설계 방법
서브넷 한번 만들면 해당 서브넷 이용하는 CIDR(Classless Inter-Domain Routing) 블록을 변경 할 수 없다.
-> 처음부터 확실하게 CIDR 설계해야한다.
- 생성할 서브넷의 수
- 서브넷 안에 생성할 리소스 수
이 2가지를 잘 고려해야하는데, 문제는 이들이 트레이드 오프 관계라는 것이다.
CIDR 블록을 서브넷 비트와 리소스 블록으로 나누어 사용한다.
서브넷 안의 리소스 수는 AWS가 예약한 5개를 제외한 값이 된다.
예를들어 서브넷 비트를 8비트로 나누면 가능한 서브넷 수는 256개이고 각 서브넷 안에 가능한 리소스 수는 251개가 된다.
서브넷 생생하기
4비트를 서브넷 비트로 설정하였다. 즉, 서브넷은 16개를 만들 수 있고, 각 서브넷에는 약 4091 개의 리소스를 생성할 수 있다.
VPC -> 서브넷 -> 서브넷 생성
VPC를 지정해주고, CIDR block을 설정해서 만들어 준다.
같은 방식으로 4개의 subnet 생성
인터넷 게이트 웨이
인터넷 게이트 웨이는 VPC에서 생성된 리소스와 인터넷 사이의 통신을 가능하게 해주는 것이다.
없으면 인터넷과 리소스가 통신할 수 없다.
VPC에 인터넷 게이트 웨이를 붙이는 것을 연결(attach)이라고 한다.
인터넷 게이트 웨이 생성하기
인터넷 게이트 웨이 생성
VPC -> 인터넷 게이트웨이 -> 생성
VPC에 연결
인터넷 게이트웨이 -> 작업 -> VPC에 연결 -> VPC에 연결
NAT 게이트웨이
게이트 웨이를 통해서 인터넷과 통신한다는 것은 결국 공개 IP를 가진다는 것이다. 하지만 공개 IP를 가지면, 기껏 private subnet을 만든 이유가 없어진다.
즉, private subnet에 생성된 리소스는 인터넷으로 내보낼 수는 있지만, 인터넷에서 접근할 수는 없어야 한다. NAT(network address translation)를 이용해서 이를 구현할 수 있다.
NAT가 private subnet의 리소스를 내보낼 수 있게 해준다
AWS에서는 NAT를 구현하는 NAT 게이트웨이를 제공한다.
public subnet에 NAT 게이트 웨이를 생성해보자.
NAT 게이트웨이 생성하기
VPC -> NAT 게이트웨이 -> 생성
이름과 서브넷을 설정해주고, 탄력적 IP를 할당해준다.
인터넷에 연결 가능한 퍼블릭 IP를 지정해주어서 인터넷 통신을 하기 위한 것이다.
라우팅 테이블
NAT 게이트웨이는 리소스가 인터넷과 통신할 수 있는 출입구라면은 경로를 알려주는 이정표가 필요하다.
라우팅 테이블이 바로 그 이정표 역할을 한다.
대상 | 타깃 |
---|---|
10.0.0.0/16 | local |
0.0.0.0/0 | internet gateway |
이러한 라우팅 테이블을 가진다. 해당 IP로 가는 통신을 타깃으로 보내라는 뜻이다.
local로 보낸다는 것은 내부통신을 한다는 뜻이다.
라우팅 테이블의 대표적인 타깃
타깃 | 용도 |
---|---|
local | 동일 VPC안의 리소스에 접근 |
internet gw | 퍼블릭 서브넷에 생성된 리소스가 인터넷 서버와 통신 |
NAT gw | private subnet에 생성된 리소스가 인터넷 서버와 통신 |
VPN Gw | VPN을 통해 접속된 독자 네트워크 상으 ㅣ서버와 통신 |
VPC 피어링 | 접속을 허가한 다른 VPC 상의 리소스와 통신 |
라우팅 테이블 이해
라우팅 테이블을 생성하면 해당 VPC 대역 -> Local 규칙이 자동 생성된다.
라우팅 테이블이 속한 VPC CIDR 범위 내로의 요청은 내부통신을 한다는 뜻이다. 어찌보면 당연하다.
0.0.0.0/0 은 모든 ip를 의미한다. 즉, 명시하지 않은 목적지에 대한 트래픽들을 한꺼번에 라우팅 시키겠다는 의미이고, 여기서는 인터넷 게이트로 타깃을 지정했다.
라우팅 테이블 생성하기
VPC -> 라우팅 테이블 -> 생성
이름과 VPC 를 지정하여 생성.
라우팅 편집
라우팅 테이블 -> 라우팅 -> 라우팅 편집
라우팅 테이블에 타깃을 추가해준다.
public subnet에 연결될 라우팅 테이블은 igw로 향하고 private subnet에 연결될 라우팅 테이블은 nat gw로 설정해준다.
서브넷 연결 편집
라우팅 테이블 -> 서브넷 연결 -> 서브넷 연결 편집
보안그룹
리소스의 접근에 제한을 걸어야 한다.
보안그룹을 통해서 접근 제한을 수행할 수 있다.
보안그룹에는 2가지를 사용해 접근에 대한 허용을 설정한다.
- 포트번호
- ip 주소
보안그룹 생성하기
VPC -> 보안그룹 -> 생성
규칙 설정
하드웨어 고장 등 예측할 수 없는 사태가 발생했을 때 시스템 자체를 사용하지 못하게 되는 것을 방지하는 능력 ↩︎